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(54) Permit for controlling access to services In protected memory systems 

(57) One ertfcodiment of the present invention pro- 
vides a method and an apparatus for controlling access 
to services In a protected memory system. The method 
mates use of a permit, which includes an access con- 
trot mechanism (500) that resides In a memory space 
that is protected from a user of the permit The msihod 
indudes receiving a request tor a service through a per- 
mit, the permft comprising an object (300) defined within 
an object-oriented programming system. In response to 
the request the method activates en access control 
mechanism within the p&mrL This access control 
mechanism controls acc es s to the service and resides 
in a memory space that is protected from a user of the 
permit such that the ac c es s control mechanism is trig- 
gered by invoking (502) a method (306-310) on the per- 
mit If the access is aflowed, the method accesses the 
service by performing an invocation (506) on a control- 
led object (320). This controlled object includes meth- 
ods (324-328) to perform the service, and is otherwise 
protected from the user of the permit Another venation 
of theabove embexfirnent includes receiving, at a permit 
issuing authority, a request for the permit from an entity 
(such as a person, a computer program or a computer 
process) requiring access to the service. If the request 
includes vafid authorisation infamiatluM , a permit Is 
issued (412) to the entity. A further variation of the 
above embodiment indudes creating a copy of the per- 
mit and transferring the copy to an entity requiring 
s to the service. 
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ent with the principles and features disclosed herein. 

Qlatrtfrtittd Cofffwter System 

[0009] Fia lAinustmtes code nwduies 102 and 104 
working together within computer system 1 00 in accord* 
ance with an errixxfiment of the present invention. In 
order to work with code module 104, code module 102 
requests services from code module 104. Similarly, in 
order to work wdh code mcdide 102, code module 104 
requests services from code module 102. Access to 
services between modules 102 and 104 is controlled 
through the permit structure described in more detail 
with reference to RG& 3-5 below. 
{00101 For purposes of this detailed description, a 
servicers a function made available by a first application 
to other applications. This function may provide the 
other appfications with access to data or to computa- 
tional resources from the first application. A protected 
memory system is a system that facilitates protection of 
selected regions of memory from an t^fcaton running 
on the system. 

[001 1] FIG. 1B illustrates how the present invention 
can be used in a client-server computer context in which 
a number of computer nodes co u p l ed together through 
a network 130 in accordance with an embodiment of the 
present Invention. In FIG. 1. servers 110 and 120 are 
coupled to third-party system 140 through network 13a 
Network 1 30 generally refers to any type of wire or wire- 
less link between computers, inducting, but not Med 
to. a local sea network, a wide area network, or a conv 
bsTCoon of networks. In one embodiment of the present 
invention, network 130 includes the Internet Servers 
1 1 0 and 120 can be any nodes on a cornputer network 
including a mechanism for servicing requests from a cli- 
ent for computational or data storage resources. ThiioV 
party system 140 may be eny node a computer network 
communteafng with servers 110 and 120 that is able to 
download code andtor data from servers 110 and 120. 
[0OI2I In the entwcUm^ Slustrmed in Ra 1. server 
110 contains server code module 112. and server 120 
contains client code module 122. Server code module 
112 and client code module 122 include modular pieces 
of code that can operate together on third -party system 
140. The dashed Ones in FIG. 1 represent server code 
module 112 and client code module 122 being down- 
loaded onto third-party system 140 across network 130. 
This downloading process can take place in a number 
of ways. In one embodiment of the present Invention, 
server 1 1 0 Ind udes a web site that can be accessed by 
a user on third-party system 140 to download server 
code module 112 onto third-party system 140. Corre- 
spondngly, server 120 includes a web site that can be 
accessed by a user on third-party system 1 40 to down- 
load dent code module 122 into third-party system 1 40. 
In another ernboolment server code module 112 and 
client code module 122 are not downloaded across net- 
work 130. Instead, they are transferred from servers 



110 and 120, respectively, to tKrd-party system 140 by 
way of cornputer storage media, such as a computer 
disk. 

[0013] Once server code module 1 12 and dient code 
5 module 1 22 are located on third-party system 1 40, they 
can be integrated to work together as Is illustrated in 
FIG. 1 . For example, in providing a service to client code 
module 122, server code module 112 might retrieve 
data from a database tor dent code module 122. After- 
10 natively, server code module 112 might perform a com- 
putational operation tor dient code module 122. This 
integration process may involve determining whether 
client code module 122 has been conferred the right to 
access services from server code module 112. In the 
13 reverse direction, this process may involve determining 
whether server code mochiie 112 has been conf e rr ed 
the right to a c cess sen/toes from client code module 
122. 

so Process of Accessing a Service 

[0014] FIG. 2 illustrates the process of accessing a 
service in accordance with an embodiment of the 
present invention. FIG. 2 illustrates Interactions 

ss between server gate 202, system 204 and client code 
module 122 (from FIG. 1). Note that the process for 
accessing a service illustrated In FIG. 2 represents onty 
one poss&e method of obtaining access to a service. In 
general, the present invention applies to any pieces of 

so code working together in a computer system. Server 
gate SK)2 is a mechanism that provides permits to prop- 
erty authorized requesters. 

[0015] For purposes of this detailed description, a per- 
mit is a token held by an entity, which allows the entity to 

35 access a service. In one embodiment of the present 
invention, a permit Includes an object defined within an 
object oriented programming system that factfitates 
accesses to a collection of services. 
[0018] Server gate 202 includes an access control 

40 mechanism that controls access to services provided by 
server code module 1 12 (from FIG. 1). This access con- 
trol mechanism can require verytng levels of authentica- 
tion from a requester of a permit. In one embodiment of 
the present invention, server gate 202 is located wtttin 

45 server code module 112 on third-parly system 140. In 
another embedment, server gate 202 is located within 
server 110 ttsett and is ac ce ssed via commurtnatiorn 
across network 130. System 204 includes a mechanism 
for establishing that client code module 122 is property 

50 authorized to access services provided by server code 
module 112. To this end, system 204 is irrpternented in 
a number of waya In one embodiment, system 204 is 
implemented by code that is part of third-party system 
140. In another ernboolment system 204 maybeimpie- 

55 merited as part of server code module 112 within third- 
party system 140. 

[0017] The process illustrated in FIG. 2 operates as 
fallows. COent code module 122 is assumed to already 
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exist within third-parly system 140. In order to access a 
desired service. cflent code module 122 requests a 
ticket" for a "rate* to access a collection of services 
from server coda module 112. A role defines a set of 
operations to be performed by server code module 112. 
Certain roiss may be more limited than other roles. For 
example, if server code module 1 12 maintains a compu- 
ter fie system, one role may Include only the operation 
of readng a ffle from the file system. Another more pow- 
erful role may indude the operations off reading, writing 
and deleting files from the file system. 
[0018] In response to the request, system 204 exam- 
ines dient oode module 1 22, to determine if diem code 
module 1 22 indudes proper authorization tor the rote. In 
one embodiment of the present Invention, this examina- 
tion includes examining a certKcate chaia This process 
is deserted in more detail in a co-pending European 
Patent Application No., entitled "Controiing Access to 
Services Between Modular Applications,* correspond- 
ing to US Patent Application Serial Na 09V 106, 567., 
which is hereby incorporated by reference in order to 
describe this process. 

[0019] lfcfiemc<xternocWe122isproperryauthon^ 
for the role, system 204 issues a ticket for the rote, and 
tfts ticket i6 grVen to dient code module 122. Next, client 
code module 122 passes the ticket to server gate 202. 
Server gate 202 checks the ticket to ensure that the 
ticket is valid. If ft is vafid. server gate 202 sends a per- 
rrit tar the service to dient code module 122. This per- 
mit allows dient code module 122 to access the 
services defined by the role. In one errtxxfiment of the 
present invention, this permit is an object defined within 
an object-oriented programming system. This object 
allows dient code module 1 22 to perform a 6et of meth- 
ods that comprise the role. After the permit is sent, 
server gate 202 invalidates the ticket so that it cannot 
be used again. Since dient code module 1 22 remains in 
possession of the permit dient code module 122 will be 
albla to access services using the permit and hence, no 
longer needs the ticket 

ParmftOblect 

[0020] FKL 3 ifiustrates the structure of a permit 
object 300 and controlled object 320 in accordance with 
an embodiment of the present invention. Permit object 
300istypicafyhetibyacfiemc^ 
ent code module 122 (tram FIG. 1), which requires 
access to services provided by a server code module, 
such as server code module 112 prom FIG. 1). Server 
code module 112 maintains controlled object 320, 
which contains code and data used to implement the 
services. Note that the embedment ilhjstrated In FIG. 3 
is implemented through objects defined within an 
object-oriented piuuj mm n in g system. However, the 
Invention Is not dmrted to object-oriented programming 
systems. 

[0021] Permit object 300 indudes a number of compo- 



nents including controlled object pointer 302, boolean 
vector 304, method-0 pointer 306, method-1 pointer 
308. method-N pointer 310, permit creation method 
312, permit expiration informatfon 314 and permit log 
5 316. 

(0022] ComjoHed object pointer 302 pdrrte to control- 
led object 320, which is maint^ 
ule 112, and thereby aiows the holder of permit object 
300 to access services associated with controlled 

io object 320 witftin server code module 112. Controlled 
object pointer 302 is stored in a memory that area that 
cs protected from accesses by cOertt code module 122. 
CQent code module 122 cannot cfirectfy read or mocfify 
controlled object pointer 302 Client code module 122 

is cannot access controUed object 320 directry. In order to 
access controfled object 320, dient code module 122 
must ask the system to access controlled object 320 
through controfled object pointer 302. Simflariy, the 
other data items within permit object 300 are protected 

20 so they cannot be (flrecdy read or modified fay dient 
code module 122. This memory protection ensures that 
client code module 122 must access services associ- 
ated with controSed abject 320 by asking the system to 
access the services. This enables the system to restrict 

25 access to the services in a manner that is specified by 
the permit 

[0023] As mentfcmed above, this type rfmera 
tectton can be provided by using the Java™ program- 
ming language and supporting interfaces. The Java™ 

30 pi uyr ai w r in g language supports memory protection 
down to the object level. Under the Java model, the only 
way to access data within an object is by invoking meth- 
ods supported by the object Data within an object is 
otherwise proteded from memory references - through 

33 a stray pointer for example. Since the Java™ program- 
ming language can be ported across a wide range of 
computing platforms, this object level memory protec- 
tion can be provided across a wide range of competing 
platforms. However, note that it may be possible to gat 

40 arouriitheprctect k x i rrechanismby attacking the inter* 
face between the Java programming language and the 
operating system on a particular computing platform. In 
order to prevent this type of attack, the Java™ memory 
protection scheme can be extended into the hardware 

48 of a computing platform. 

[0024] Boolean vector 304 contains entries corre- 
sponding to methods provided by controfled object 320. 
These methods implement the services associated con- 
trolled object 320. If an entry indudes an 'ALLOWED* 

so varue,thts Indicates that the hdcterc* permit object 300 
is allowed to access the corresponcSng method that 
implements the service from controlled object 320. If the 
entry includes a "NOT AUjOWHT value, this indicates 
the holder of the permit Is not aflowed to access the cor- 

55 responding method In this way, permit object 30O spec* 
ifies which services the holder of the permit is aflowed to 
access. Since boolean vector 304 is located in pro- 
tected memory, a holder of permit object 300 cannot 
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modify boolean vector 304 to gain unauthorized access 
to a service. Note that there are many possible ways to 
indicate that particular methods are not allowed. In 
another embodment, methods within permit object 300 
are coded to call a corresponding method in controlled 
object 320. Ofcerwise. they are coded to cncScate thai 
tha method is not allowed. 

[0025] The methods specffied in controlled object 320 
are accessible through method pointers within permit 
object 300. These method pointers include method-0 
pointer 306, method-1 pointer 308 and method-N 
pointer 310. Client code module 122 must access meth- 
ods 324, 326 and 328 through these method pointers 
306. 308 and 310. Method-0 pointer 306 points to 
method-0 324 within controlled object 320. Method-1 
pointer 308 poortis to method-1 326 within controlled 
object 320. Method-N pointer 310 points to method-N 
328 within controfled object 320. These metrtod pointers 
reside in protected memory so that client code module 
122 must ac cess the methods through the system. 
[0026] In the illustrated ernboolment permit object 
300 additionally includes permit creation method 312. 
which allows a holder of permit object 300 to create a 
copy of permit object 300. and to transfer the copy to 
another appficatton. Th» allows client code module 122 
to farm out a sub-task requiring services from controlled 
object 320 to another module. Note that permit creation 
method 312 allows only less powerful copies of permit 
object 300 to be mada In other words, copies of permit 
object 300 can access at most the same methods from 
controfled object 320, and possibly fewer methods. 
[0087] Permit object 300 additionally includes permit 
expiration information, which specifies some type of 
lifespan limitation tor the permit. In one embodiment, 
this is accomplished by specifying a certain time period 
during which the permit is vafid. In another embocSmant 
this is accomplished by requiring that the system first 
check in a central database to see that the permit 
remains still valid. 

[0028] Permit object 300 also includes permit log 31 6. 
which records a log of access requests to permit 300. 
This log can be used tor security purposes to monitor 
how permit object 300 is being used. Alternatively, a log 
of acc es s requests can be maintained withki controlled 
object 320. 

[0029] Controlled object 320 contains data 322, which 
is used by methods 324, 326 and 328 to Implement 
services associated with controlled object 320. For 
example* data 322 may contain fie system data and 
methods 324, 326 and 328 may specify Me system 
operations. 

Ptrmtt Create! 

[00301 PIG- 4 is allow chart illustrating the process of 
creating a permit object In accordance with an embocB- 
ment of the present invention. TWs flow chart describes 
in more detail the operations performed by server gate 



202. which were described previously with reference to 
FK1 2 above. The system starts at state 400 and pro- 
ceeds to stat 402. in state 402, client code module 1 22 
performs an invocation on server gate 202 to make a 

5 new permit As mentioned above, this invocation 
incfcides a ticket for a role as a parameter. The system 
then proceeds to state 404. In state 404, server gate 
202 authenticates the ticket, and if ft is valid, server gate 
202 makes a new permit object 300. This process may 

io include locating a controlled abject 320 to associate 
with permit object 300, or if necessary, making a new 
controled object 320 within server code module 112. 
The system next proceeds to state 406. In state 408. 
controfled object pointer 302 (from FIG. 3) is assigned 

15 to point to controlled object 320. The system next pro- 
ceeds to state 410. In state 410, the system sets access 
control flags (entries in boolean vector 304) to specify 
which methods the holder of the permit is allowed to 
invoke. The system next proceeds to state 410. In state 

zo 410, permit object 300 is returned to client code module 
1 22. The system next proceeds to state 41 4, which is an 
end state. 

Use of Permit Obtect 

[P031] FIG. 5 is a flow chart iustrating the process of 
using a permit object to access a service in accordance 
with an embodiment of the present invention. The sys- 
tem starts at state 500 and proceeds to state 502. In 
so state 502, efientcode module 122 (from FIG 1) invokes 
a method on permit object 300 prom FIG. 3). The sys- 
tem proc eeds to state 504. In state 504, the system 
checks acc ess control flags corresponding to the 
method. This entails looting up an entry in boolean vec- 

6 tor 304 corresponcfing to the eivoked method. If this 
access control flag indicates the method is allowed, the 
system proceeds to state 506. Otherwise, the system 
proceeds to state 510. 

[0032] in state 506 the access is afiowed, so the sys- 
40 tern invokes the appropriate method on permit object 
300, which causes a corresponding method to be 
invoked on controlled object 320 with the appropriate 
parameters. The system next proceeds to state 50a, In 
state 508, the system waits tor the invocation to com- 
4B piete, and then returns a result to client code module 
122. The system next proceeds to state 512, which is an 
end state. 

[0033] In state 510, the method is not allowed. In this 
case, the system indicates to effent code module 122 

so that the method is not allowed. This can be done in a 
number of ways. In one ernboolment of the present 
invention, the system causes an exception to occur in 
the execution stream of a processor p ei fa n ning the 
method invocation. In another embodiment the system 

33 sets a global variable to indicate that the attempted use 
of permit object 300 tailed. In yet another ernbocSment 
the Invocation to permit object 300 returns a NULL 
value. Trie above process is repeated for successive 
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invocations on permit object 300. 
[0034] The foregoing descriptions of ennbodiments of 
the invention have been pres rtted tor purpcsesof illus- 
tration and description on!* They are not Intended to be 
exhaustive or to limit the invention to the forms dls- 
dosed. Aocortiirttfy, many mocSfications and variations 
wiB be apparent to practitioners skilled in the art 

Claims 

JO 

1. Ametrtodfor<»crtroUmg access to services in a pro- 
tected memory system, comprising: 

receiving a request tor a service through a per- 
mit tie permit comprising an objec t (300) n 
defined within an object-oriented programming 
system: 

in response to the request activating an 
access control rrwchantem (500) within the per- 
mit the access control mechanism coirtroffirtg 20 
access to the service and resfcfing in a memory 
space that is protected from a user of the per- 
rrtt such that the access control mechanism is 
triggered by invoking (502) a method (306-310) 
on trie permit; and 25 
if the access is aflowed, accessing the service. 

2. The method of claim 1. wherein the access control 
mechanism (500) provides access to the service by 
performing an invocation (506) on a controlled so 
object (320), the controlled object inducting a 
method (324-328) to perform the service, and oth- 
erwise being protect ed from the user of the permit 

3. The method of claim 1 or claim 2. further compris- 35 
ing if the access is not slowed. incficating (510) to 
an entity requesting the service that the access to 
the service is not allowed 

4. Therr*triodGf claim 1 or daim£ the par- <o 
mrt (300) is defined within the Java m programming 
language and supporting interfaces. 

5. The meftod of any one of claims 1 to 4, wherein 
data (322) protected by the permit (300) can only 45 
be arfftfffr^ through methods (305-310) invoked 
on the permit 

6. The method of any one of daims 1 to 5. further 
comprising! *® 

receiving, at a permit issuing authority, a 
request tor the permit from an entity requiring 
access to the service: and 
if the request indudes valid ai/thorisatfon infer- a 
matioa issuing the permit (412) to the entity 

7. The method of any one of daims 1 to 6, further 



comprising creating a copy of the permit (300) and 
transiting th copy to an entity requiring access to 
th service. 

5 8. Tr*melriQdddaim7. wherein the «w of the per- 
mit allows access to fewer services than the permit 
(300) that it was copied from. 

9. The method of any one of claims 1 to 8, further 
oomprising determining whether the permit has 
been revoked before accessing the service, and 
bean revoked, incficating (510) the access is not 
allowed. 

0. The method of any one of claims 1 to 9, further 
comprising recording the access request in a log 
(316) associated with the permit 

1. The method of any one of daims 1 to 10, wherein 
activating the access oontrol mechanism indudes 
determining (314) whether the permit has expired. 

2. The method of any one of claims 1 to 11. wherein 
the access control mechanism indudes a pointer 
(302) to the controlled object (320). the pointer 
residing In the memory space that is protected from 
the user of the permit 

13. Themethodof anyone of daims 1 to 12, wherein 
the access control mechanism indudes a method 
(324*328) to be invoked to perform the service, 
wherein if access is not allowed, the method (324- 
328) does not perform the service, but instead indi- 
cates (510) that access to the service is not 
allowed. 

14. The method of any one of daims 1 to 13, wherein 
the access control mechanism indudes a variable 
(304) associated with a method to be invoked to 
perform the service, wherein the variable indicates 
whether the access is allowed. 

15L A computer readable storage medium storing 
instructions that when executed by a computer 
ca\ffi9 the computer to perform a method for con- 
trolling access to services in a protected memory 
system, comprising: 

receiving a request for a service through a per- 
mit the perms comprising an object (300) 
defined within an object-oriented programming 
system; 

In response to the request activating an 
access control mechanism (500) within the per* 
mit the access control mechanism controlling 
access to the service and residing in a memory 
space thrt is protected from a user 
mit such that the access control mechanism is 
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triggered by invoking (502) a method (306-31 0) 
on the permit; and 

if the access is allowed, acces s ing the service 
by performing an invocation (506) on a control- 
fed object (320), the controlled object including 
a method (324-328) to perform the service, and 
otherwise being protected from the user of the 
permit 

16. An apparatus for controlling access to services in a 
protected memory system, comprising: 

a permit means through which a user can 
access a service* the permit means optionally 
. comprising an object (300) denned within an 
object-oriented program rung system; 
an access control means (500) within the per- 
mit the access control means controlling 
access to the service and residing in a memory 
space that ts protected from a user of the per- 
mit such that the access oontrot means is trig- 
gered by invoking (502) a method (308-31 0) on 
the permit; and 

a request processing means, in communication 
with the permit means, that is configured to 
receive an access request for the service 
through the permit means, and to activate the 
ac tirt tt contiol means. 

17. The apparatus of claim 16, wherein the access con- 
trol means (500) is configured to provide access to 
the service by performing an invocation (506) on a 
controled object (320}, the controlled object includ- 
ing a method (324-328) to perform 

otherwise being protected from the user of the per- 
mit (300). 

1a The apparatus of claim 16 or claim 17, wherein the 
request processing means is configured to indicate 
(51 0) that the access to the service is not allowed if 
the request proce s sing means determines that the 
access is not allowed. 

19. The apparatus of any one of claims 16 to 18, 
wherein the access control means (500) includes at 
least one method (324-328) to be invoked to per- 
form the service. 

20. The apparatus of any one of claims 16 to 19, 
wherein the permit (300) is defined within the 
Java 111 progr a rnming language and supporting 
interfaces 

21. The apparatus of any one of claims 16 to 20, 
wherein data (322) protected by the permit (300) 
can only be accessed through methods (308-310) 
invoiced on the permit 



22. The apparatus of aiw one of claims 16 to 21. further 
comprising a permit creation mechanism (400) that 
receives a request tor th permit (300) from an 
entity requiring access the service, and if the 
s request includes valid authorisation information, 
issues (412) me permit to the entry. 

23L The apparatus of any one c^dainrts 16to22, further 
comprising a permit copyfrig mechanism that is 
10 configured to create a copy of the permit (300) and 
to transfer the copy of the permit to an entity requir- 
ing access to the service. 

24. The apparatus of any one of claims 18 to 23, 
is wherein the permit copying mechanism is config- 
ured to produce the copy of the permit that allows 
access to fewer services than the permit (300) it 
was copied from. 

20 25. The apparatus of any one of claims 16 to 24, 
wherein me request processing means is config- 
ured to determine (504) whether the permit has 
been revoked before accessing the service, 

25 26. The apparatus of any one of claims 1 6 to 25, further 
comprising a log (316), associated with the permit 
to record access requests. 

27. The apparatus of any one of claims 16 to % 
30 wherein the request processing means is config- 
ured to determine (314) whether the permit has 
expired. 

2a A data structure contained in a computer readable 
as storage medium tor controIBng access to services 
in a protected memory system, the data structure 
comprising: 

an access control mechanism (500) within the 
40 data structure, the a cc ess control mechanism 

controlling access to the service and reskflngtn 
a memory space that is pr otec ted from a user 
of a permit (300), such that the access control 
mechanism Is triggered by invoking (502) a 
45 method (388-310) on the permit; and 

an access control indicator (304) within the 
data structure, the access c ontrol indicator 
specifying services ihe user can access, the 
ac cess control indicator being protected from 
» morff Icafi on by the user. 

29. The data structure of claim 28, wherein the access 
control mechanism (500) includes a pointer to 
code(324-328) that implements the service, the 
& pointer residing in the memory space that is pro- 
tected from the user. 

30i The data structure d daim 28 or claim 29, wherein 
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the access control indicator (304) includes a vans- 
bl associated with a service, wherein the variatt 
IncScates wh ther access to a corresponding serv- 
ice is allowed. 

5 

31. A computer program or applet encoding a set of 
computer instructions for controlling access to serv- 
ices to a protected memory system which when 
running on a computer Is adapted to perform the 
method of any one of daimsl to 14. w 
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